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Graphics for Display 
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The C++ code for the BITGDI is also maintained for the PC-hosted emulator (which runs on 
300+MHz Pentiums and hardly needs optimizing), and as a starting point for ports to other CPU 
architectures (such as Motorola's M*Core). 


We can now explain the DrawTilesNow() function that we saw earlier: 


void CFleetView: :DrawTilesNow() const 


Window() . Invalidate (iSeaArea) ; 
ActivateGc () ; 

Window () .BeginRedraw (iSeaArea) ; 
DrawTiles() ; 

Window() .EndRedraw() ; 
DeactivateGc () ; 


} 


This is a member function of CFleet View, which is derived from CCoeControl. The central function 
is DrawTiles (), but this is bracketed by actions necessary to function correctly with the window 
server, 


invalidating 


First, we use an Invalidate() function to invalidate the region we are about to draw. 


Remember that the window server keeps track of all invalid regions on each window, and clips drawing 
to the total invalid region. So before you do an application-initiated redraw, you must invalidate the 
region you are about to redraw, otherwise nothing will appear (unless the region happened to be invalid 
for some other reason). 


| Activating the Graphics Context 


Then, CONE's system graphics context must be activated. If you take a look in coecntrl.cpp, you'll 
find that CCoeControl: :ActivateGc() is coded as: 


EXPORT_C void CCoeControl: :ActivateGc() const 
{ 
CWindowGc& gc = iCoeEnv->SystemGc(); 
if (iContext) 
iContext->ActivateContext (gc, *iWin) ; 
else 
gc.Activate(*iWin) ; 
} 


The usual case just executes gc .Activate() on the control's window, telling the window server's 
client interface to use CONE's system GC to start drawing to it. The function also resets the window GC 
to use default settings. I'll explain the other case later on. 
































